As technology advances, computers provide increasingly useful and rapid service to their users. Much of the advantage provided by computers, however, arises as a derivative of the increased processing speed, that is, the ability to run larger and more complex programs. Of course, many tasks performed by a computer, such as clearing a display of graphics, connecting to a network, etc. are repetitive. Thus, one method of simplifying the job of programming is to re-use software routines as much as possible. As software continues to evolve, then, and programs become more complex, increasing reliance is placed on the re-use and recycling of various modules which support application program operations. Software modules or subroutines which are routinely used by other programs are often grouped into a single program file, known as a “library”.
Using the Microsoft Windows™ Operating System (hereinafter “Windows™”) as a well-known example, it is understood by those skilled in the art that a popular library file type can be recognized in a file listing by the appended designation characters “DLL”. Those who formulate these dynamic link library files, or “DLL files” often intend that they be used by many different programs. However, just as for any other type of software, DLL files are subject to constant improvement and upgrades. And, as is also the case for most other software, upgrades for DLL files are typically published under a new version number.
For example, an application program might make use of a DLL file having the name “testlibrary.dll”. This library may be published, upon initial release, with a version number of “1.0”. Minor upgrades or changes to Version 1.0 might in turn be published with a version number of “1.05” or “1.1”, and would include small revisions to improve the function of the program, or possibly to correct minor flaws in operational functionality. Major changes will usually be accompanied by greater changes in the version number, such as “2.0” or “3.1”. Thus, by tracking the version number attached to any particular software code or library, it is possible to gain an idea as to whether the most recent version of software is being used. More important, observing the version number attached to the software code will also give information as to whether the correct version of the code is being used.
Most software application programs make use of auxiliary software codes, including libraries, such as the exemplary DLL files described above. One of the most common problems when using such software codes is loading an improper version of the code by the application software, which may occur in several different ways. For example, one application may load one version of a DLL file, while another instance of the same application loads a different version of the same DLL file. Alternatively, a single application might load a DLL file version that differs from a previously-loaded version. Either occurrence might cause the application to perform erroneously. Thus, in each case, the application has loaded an improper version of the auxiliary software code. This problem usually arises after an end user, unaware of the specific interaction between a particular program and its associated auxiliary software codes, attempts to improve his system by “upgrading” to the latest version of an application program. Either the application expects to use a newer version of the auxiliary code in question, or upgrading to a particular auxiliary code may clash with other application software that has been modified to operate with a previous version of the code. In any event, incorrect answers, unexpected operations, or even catastrophic failure may result.
Computer systems have historically been rather poor at alerting the system administrator and/or end user as to the root cause of such problems. Thus, determining the cause is often a time-intensive and costly exercise. Unfortunately, the frequency of occurrence for such problems increases with the growing number of application programs attempting to use (or re-use) commonly-available auxiliary software codes, such as, for example, the DLL files provided for use with Windows™.